AWS SNS
マネージドPub/Subメッセージングサービス 公式
メッセージは構造化されていない→AWS EventBridge
コンポーネント間の連携検討ポイント
https://gyazo.com/ca0b9326f534ea780a200500833a8803
hiroki.iconふき出し感でメッセージを表している
SNSを活用できると一気にawsでサービスを組み合わせて実現できること増えるな
Akkaとかを使ったシステムを構築してもいいけど、パターンによって使い分けだな
https://gyazo.com/0789b802017602b9839359f67ff924c2
ポイント
pubとsubそれぞれが知っているのはtopicだけなので疎結合になる
二つの機能
モバイルプッシュ→AWS Pinpointとか
pub/sub
リソースベースポリシー
メッセージは即時配信される
SQSと組み合わせる
即時性が必要ない
通知の信頼性の向上
バックエンドでタイミングをコントロールしたい
Lambdaを噛ませることで多様なサービスにファンアウトできる
ベストプラクティス
トピックがパブリックアクセス可能でないようにする
最小特権アクセスの実装
Amazon SNS アクセスを必要とするアプリケーションと AWS のサービスには IAM ロールを使用する。
サーバー側の暗号化を実装する
転送時のデータの暗号化を強制する
VPC エンドポイントを使用して Amazon SNS にアクセスすることを検討する
VPCラムダみたいなやつだよね
Q. ユースケースで、S3からのイベント連携でSNS→SQSの流れがありましたが、S3→SQSもできると思います。メリデメ等差があるのでしょうか。
A. 単純にAmazon S3のイベントに対して1つの処理を実行する場合は、Amazon S3からAmazon SQS、あるいはAmazon S3からAWS Lambdaでも良い場合があります。Amazon SNSはパブリッシュ、サブスクライブパターンを実装するのに適したサービスでひとつのトピックに対して複数のアクションを実行する場合に特に有効です。
hiroki.iconSNSを噛ませることで一気にファンアウトできるよね→複数のアクションへつなげる場合にSNSを噛ませるのが有効
デッドレターキュー
SNSトピックからサブスクリプションに到達不能になった場合にそのメッセージを保持するためのキュー
/icons/hr.icon
https://youtu.be/bPCjOG_jQlc
https://gyazo.com/a702de788632f50b5a9aa906375d7544
https://gyazo.com/8c2fea4b745295b0f335300e8a5a2f8b
https://gyazo.com/309af9ecbbed14ea50491380597bc09a
https://gyazo.com/7754c1ca8fa88e3fcff534f3a9953d6c
https://gyazo.com/0324ef2e635275ac988000fd0985652e
https://gyazo.com/5aa1f1e711f989f848e0398c26332bf7
hiroki.iconプログラミング言語の処理を挟めるから高度なフィルター処理とかをかけるってことだけど、高度な処理が必要な場合とかはAkkaとかで構築した方がいいかも？
https://gyazo.com/5d81da01ccc115124f5c41fadc7fdc0d